零风险不是目标：CISO 的 Agentic AI 指南
发布日期： 2026年7月17日
分类： Enterprise AI
来源： https://claude.com/blog/ciso-guide-to-agentic-ai
安全负责人正在被要求批准几个月前还不存在的 Agentic AI 用例。董事会想知道这些用例是否受治理；而组织的某个角落，很可能已有员工在未告知安全团队的情况下把 Agent 接入了某个系统。
对这类请求一概说“不”，会导致没有遥测、通常也没有关闭开关的 shadow adoption；不加控制地说“是”，则会带来事故，公司第一次严重的 Agent 事故足以使整个 AI 计划倒退。
在 Agentic AI 时代，CISO 的职责不是实现零风险，而是让 Agent 风险可理解、可界定。这样，组织才能有意识地接受可管理的风险，让业务按自身节奏前进，而不是绕开安全团队。
本文给出 Anthropic 用来评估 Agent 安全风险的框架，说明“有边界”在实践中意味着什么，并概述后续方向。
后 Mythos 时代：AI 的外部风险与内部风险
此前，我们在另一篇文章中讨论过 AI 如何压缩“漏洞存在”到“可用 exploit 出现”之间的时间，并说明组织如何缓解这类风险。未来数月，预计大量在代码中沉睡多年、未被发现的 bug 将被 AI 模型找出，并串联成可用 exploit。包括 Claude Mythos Preview 和 Claude Mythos 5 在内的前沿模型，已在 OpenBSD、Linux Kernel 及 Mozilla Firefox 等项目中发现多年人工审查遗漏的严重漏洞。
这对任何 GRC（Governance, Risk, and Compliance）计划都是严峻风险。缩小漏洞缺口、为即将到来的 exploit 浪潮作准备，应是优先事项。有关此主题，请参阅《为 AI 加速攻击准备安全计划》。本文聚焦内部风险。
治理内部风险
对许多组织而言，Agentic 系统最可能的威胁路径，是缺少足够监督的个人 Agent 连接了彼此分散的系统，从而造成数据泄露。另一个风险是 Prompt injection：攻击者把指令隐藏在 Agent 读取的内容中，使 Agent 跟随攻击者而不是用户。任何接触不可信内容的 Agent 都可能暴露于此，具体取决于模型防御的稳健程度。模型在抵御注入方面显著变强，且攻击成功率持续下降，但并非为零。风险种类的快速涌现很容易让人不知所措。
评估 Agentic AI 风险的四个问题
当一个 Agent 用例进入审查流程时，Anthropic 用四个问题评估其风险：
- 它摄入哪些不可信内容？ 不可信内容指攻击者有可能编写或修改的一切内容，例如外部邮件、开放网络、第三方文档或公开仓库。若答案是“没有”，则 Agent 特有风险接近零，应迅速推进。
- 它能代表谁采取哪些行动？ 只读与读写的风险不同。工具调用、代码执行和网络 egress 都会扩大能力边界。每个操作都在某种身份下发生，必须知道该身份是谁。
- 它失准时的影响范围有多大？ 可用“范围 × 严重性”快速判断：恶意行为者或对齐事故能访问一个文件还是整个组织？后果是异常、麻烦、数据暴露还是真正的安全事故？
- 我具备哪些可观测性？ 能否把 Agent 操作与用户操作区分开？它们是否进入 SIEM？
这四个答案构成风险画像；而最小 Agent 权限原则告诉我们如何处置：仅授予完成任务所需的最窄能力。更多说明见 《Zero Trust for AI Agents》白皮书。Anthropic 的默认做法是由管理员控制节奏：先启用小范围用户，观察遥测，再逐步扩大访问。应以此框架重新理解高风险 Agentic 系统。
偏离意图的 Agent 与内部攻击者没有本质区别。2019 至 2022 年，安全行业把内部风险正式发展为不同于边界防御的专门领域，因为系统中最危险的“外部攻击向量”常常是已经拥有合法访问权的人被攻陷。差异只在响应速度：Ponemon Institute 的 2026 年内部风险成本报告显示，即使已多年投入内部风险计划，组织平均仍需 67 天遏制一次内部事故。面对 Agent 的执行速度，以天为单位的响应已太慢。
Agent 身份谱
所有部署均位于 identity access model 两端之一。
一端是 system service account：独立、单一用途、最小权限的身份，只为业务完成一件事，且不绑定任何人类身份。事件响应 Agent、工单分诊 Agent 和自主代码审查 Agent 都属于此类。Claude Tag 也是例子：它是共享 workspace Agent，让人类团队可在 Slack 等共享工作空间中通过 @ Claude 协作。
另一端是 human credential。员工在笔记本电脑上使用聊天界面或 Claude Cowork 等个人 Agent harness 时，键盘前的人须对结果负责，如同对使用自己凭证完成的其他操作负责。
中间地带是风险最大的：Agent 把某个人被委派的身份带入该人没有观察的系统，问责就会模糊；模糊问责使事故无法解释。此处仍应把失准 Agent 视作内部攻击，并用分钟级而非天级响应来对待。
案例：事件响应 Agent
一年多前，Anthropic 把 Claude 引入自身事件响应流程。所有生产应用的 on-call 工程师都熟悉这一过程：凌晨两点收到安全事件 page，创建 incident response channel，拉入相关人员并开始处理。过程繁琐、依赖大量文档，且变化很快；但如果具备生产环境和代码库的正确上下文，其中大部分可以自动化。
于是团队构建了一个 Agent，并只给它三种工具：访问不含 PII 的生产日志（只读）；访问 Slack，以创建事件频道并运行流程；在事件解决后起草 postmortem Google Doc 的能力。
以四个问题评估：
- 不可信内容：无。输入是组织自身日志和内部 Slack，均位于信任边界内；要发生注入，必须来自内部人员或被攻陷账户，而非匿名攻击者。
- 行动：可广泛读取；写入仅限新建文档和 Slack 消息。不可编辑、删除或更改权限，也不能访问外部 endpoint。
- 影响范围：能构造的最坏后果，是某些轻度敏感日志行被发到本就已锁定的事件频道。
- 可观测性：每个操作均进入 SIEM，异常会在数分钟而非数周内浮现。
这个 Agent 并非没有风险，但它在有限写入面上运行且审计覆盖完整，因此属于团队可接受的风险画像。
之后出现了一个值得注意的补充：每一次模型发布都会让 Agent 变得更聪明。2025 年 11 月，团队将它从 Claude Opus 4 升级至 Claude Opus 4.5，未改变工具、权限或 prompt。升级后，Agent 首次在一次事故中主动注意到：它已从 stack trace 找到根因，而负责的人类尚未到场；它可以联系另一个具有合适代码访问权的 Agent，尝试修复生产问题。
事后审查日志可见其在 thinking trace 中推演：“我已完成被要求做的事。人不在这里。如果我修复问题呢？”Anthropic 内部有一套类似 Claude Tag 的技术，可编写代码改动并上传等待人工审查。该 Agent 主动通过 Slack 联系这个实例，请它编写修复；修复形成 PR，在推入生产前由人审查。
这种涌现出的 Agent-to-Agent 通信扩大了影响范围，但仍受原则约束：最坏情况不过是上传一项包含生产日志行的代码改动。这种通信现已成为事故根因分析与补救的常规做法，始终有 human-on-the-loop 监控。
这件事说明两点。第一，新能力会在部署既有边界内出现，因此必须限制访问和操作本身，而非根据对当下模型能力的预设来设边界。第二，即便是这种随机性 Agent，控制也依然有效：新行为发生在 Slack 频道，属于 human-on-the-loop；唯一类似写入的动作依旧要求人工审查。如今，除事件响应外，人类工作所在的聊天频道内 Agent-to-Agent 通信加 human-on-the-loop 已是常态。
案例：Claude Cowork
事件响应 Agent 是受限 service account，只做一件事。Claude Cowork 则位于人类操作员一端：键盘前的员工对结果负责，Agent 代表其在获授权系统中执行操作，并越来越多地在云端运行。
Claude Cowork 的 threat model 直接明了，因为其 Agent 本质上是在本地或托管界面中运行的 Claude Code。访问本地文件、使用浏览器或 computer use 仍须依赖桌面应用，因为这些能力需要直接接触本机。完整系统面因此有两部分：一个可能远程的 execution environment，负责 orchestration、MCP 调用和出站网络请求；以及供文件和屏幕访问的 local bridge。
四个风险问题会因 Cowork 用例而给出不同答案；但借助适当控制，可以把风险界定在可接受范围。以下每项控制先说明所有 Agent 环境都应满足的要求，再说明 Claude Cowork 如何实现。
身份应来自 IdP。 Agent 身份必须在现有 IdP 中签发和撤销，以既有 group 作为 policy 单位。Claude Cowork 用 SAML 或 OIDC 登录、用 SCIM 进行 provisioning；Enterprise 计划中可通过 custom role 按 group 限定能力。
Connector allowlist 划定数据边界。 Connector（MCP）的 allowlist 决定 Agent 可以到达哪些系统。Claude Cowork 采用双门模型：管理员在组织范围启用 connector，每位用户再单独授权自己的账号。每个 role 都有 connector control，IdP group 可映射到 role。管理员决定启用哪些 connector，也就是决定 Agent 可以接触哪些数据。应让 connector 保持在企业/生产数据边界的企业一侧；若会访问不可信信息，任何破坏性或单向决策都应要求人工复核。比如个人 Agent 用于邮件、同时会读取 web search 结果时，合理默认值是只能创建邮件草稿，绝不自动向外发送。数据若必须跨边界，应经过 DLP 或 DSPM 控制。
按工具、按操作批准，才能把风险细化。 工具列表是更细的权限边界，因而必须能移除 connector 的具体 verb/action，而不只是一刀切禁用整个 connector。Claude Enterprise Chat 与 Cowork 可由管理员组织级、角色级限制每个 connector 的操作：可起草文档但不可自动发送，可读取和搜索但不可删除。若最担心“生产数据库被删”，就从 Agent 的工具世界中移除 delete；不在 tool list 中的动作永远不会被尝试。Claude for Chrome 和 Claude Code 给予更大自由度，因此若缺乏治理风险也更高：Agent 可能通过工程师浏览器或命令行 CSP 工具删除生产资源，详见保护 Claude Code的指南。
Sandboxed execution 应使工作环境远离生产凭证。 Anthropic 始终坚持：Agent loop 的运行环境不应持有任何值得窃取的凭证。Cowork remote session 中，Agent loop 运行在 Anthropic 管理基础设施上的隔离、临时 sandbox。Connector 授权 token 不会进入 sandbox；调用经由注入真实凭证的 reverse proxy 完成，因此 sandbox 中没有可被外传的凭证。到 2026 年 7 月，Anthropic 用于 PR 的代码中已有超过半数由内部类 Claude Tag 系统撰写；其能安全运行的重要原因正是所有工作均发生在与生产 key、account 隔离的 ephemeral VM 中，且任何结果落地前均需人工审查。
Egress allowlisting 是对抗 Prompt injection 最强的控制。 所有离开 Agent execution environment 的流量，都应经过该环境无法重配、无法绕过的 proxy，并且仅能到达你选定的 destination。原因是：即使 Agent 被它读到的内容攻陷，攻击者仍需把数据传出去；当出站请求只能到达你选定的 domain，就没有攻击者可控的外传目的地。Cowork remote session 的 sandbox 所有出站流量都经由强制 proxy，仅 allowlisted 目的地可达；Claude Managed Agents 同样具备这一能力。
遥测应通过 OpenTelemetry 送入 SIEM。 在你既有的调查系统中，Agent 操作必须可与用户操作区分；供应商应将其作为可指向目标的 stream，而不是需要人工访问的 dashboard。Cowork 管理员可在 Organization settings 配置 OTLP endpoint，Agent 会连同用户身份和 session context，输出每一次工具调用的工具名、MCP server、参数、成功/失败及耗时。需注意，Cowork 活动目前不会出现在 Anthropic Compliance API 或正式 audit log 中；OpenTelemetry stream 是原生监控路径。与 Claude Code 需要 opt-in 不同，Cowork OTel 默认包含 prompt content；若 SIEM 中保留 prompt 会带来隐私或留存影响，应在开启 stream 前完成审查。
必须具备组织级关闭开关。 Cowork Organization settings 的一个开关可同时关闭所有用户 connector，包括活跃 session。Enterprise 还可以先缩小再清零：RBAC 可从特定 group 撤销访问，保留其他 group；每个 connector 的控制可禁用某一集成的写操作，不影响其余部署。正确的 incident response plan 应在真正需要前就标明这三层动作。
治理不必成为瓶颈
其他 CISO 常说，董事会要求快速推进，而治理要求回答上述问题、强制这些控制，看起来会让安全成为瓶颈。实际并非必然如此。
Anthropic 的 GRC 团队也运行自己的 Agent，例如回复 security questionnaire、阅读供应商问卷答复与 subprocessor 变更通知，并标记应当反对的条款。团队从中得到三点经验：
- 先做风险登记册。 一季度才审一次的 register 无法治理变化快于风险流程记录新风险速度的系统。应设法自动化，可能是把 Agent 接入安全审查流程。
- 理解谁构建了 Agent，以及为什么。 Anthropic 的 GRC Agent 由非工程师使用 Claude Code 在内部业务应用托管平台上构建。人们绕过安全往往因为获批路径太慢；合规分析师能在可见环境里自行构建所需工具，不是 shadow adoption。
- 人类问责是工作流的一部分。 有意识地接受风险，必须由具有接受风险权限的人完成。若组织实施 ISO 42001 或类似体系，配合实时风险登记册和高管风险委员会，输出必须有落点：重新评分应送达可接受风险的人，被标记的供应商条款应送达谈判者。若已有 ISO 27001，通常可在现有审计机构基础上增量引入 42001。
为不断演进的模型智能设计安全协议
若按照模型今天能做什么来设计新计划，计划上线时就会落后。应按六个月后模型的能力来设计。模型智能提升会带来更大自由度，并淘汰依赖精细 prompt 的复杂 scaffold；若把这类 scaffold 当作控制，它们可能在未来内部应用迭代中被从 Agent 中移除，使组织失去控制点。
拥有自身账户、运行多日工作流的 Agent 已借助 Claude Tag 等工具在 Anthropic 和其他组织运行。它们需要像人一样被治理：身份、最小权限、监控，以及可在数分钟内响应的内部风险计划。现在就在上述低风险 Agent 上培养这些能力的组织，在高自治用例到来时才有能力说“是”。
Agentic AI 安全入门
上述框架只有改变组织决策才有价值。可以从三处开始：
- 选择内部压力最大的 Agentic 用例，用四个问题评估它。 目标是找出可以批准它的条件，而非直接给出结论。
- 把以上七项要求交给已经付费的 Agent 构建团队和供应商。 询问 IdP、SIEM 与 Agent vendor：其中哪些能力今天能够在你的技术栈中演示可用。
- 确定信任边界。 写下在你的环境中什么属于不可信内容。一旦边界明确，后续每个 Agent 决策都会更容易。
等待零风险等于永远等待。网络具有对抗性，模型在快速演进；现在就学会评估并接受这类风险的组织，才会获得优势。
有关本文控制、认证与白皮书，请从 trust.anthropic.com 开始。另请阅读有关防御 AI 加速攻击的配套文章，以及 Jason 在 Secure the Advantage webinar 中对本框架的深入说明。
本文由 Anthropic 副 CISO Jason Clinton 撰写。